The Open System Interconnection (OSI) reference model provides a conceptual framework for networking communications. The OSI reference model divides communications into seven layers, the topmost or seventh layer being the application layer. In general, the application layer provides an interface to user processes. For example, a test application program, running in an operating system environment, typically communicates with the application layer, but cannot interface with any of the other host layers, such as the Presentation, Session, and Transport layers. Communications, according to the OSI model, pass up or down from layer to the next layer.
The OSI model, however, presents a disadvantage to diagnostic testing. A primary objective of the OSI model is to achieve successful communication between networking hosts; the OSI model concerns itself with successful, accurate data transmission. To achieve this aim, the OSI layers may employ error recovery mechanisms. As long as the communications are successful, the recoverable errors can remain unreported.
Moreover, interactions with the host layers of the OSI model do not necessarily result in predictable or deterministic results in the media layers, namely, the Network, Data Link, and Physical layers. Yet predictable or deterministic results are essential for test or diagnostic purposes. For example, the host layers cannot create faulty data packets or precisely control the timing of physical layer interactions. In addition, the protocol restricts the manner by which the host layers handle data transmission over shared media.
Another approach to diagnostic testing involves directly acting on the physical hardware device itself. To some extent, the interaction with the physical device may involve reproducing relevant portions of the OSI model in order to exercise the functionality of the physical device. In such instances, the aforementioned criticism comes back into effect. Otherwise, the diagnostic testing manipulates the physical device in raw fashion. Irrespective of whether the diagnostic software tests the physical device indirectly through an OSI layer or directly through direct control, it is still problematic that the diagnostic software treats the physical device as a separate, single component in a computer module. Often, for diagnostics purposes, it is more desirable to treat and test the computer module as a functional whole.
A variation of this approach is to conduct diagnostic tests through an interface provided by a software driver. However, the interfaces of typical software drivers are usually designed to fit into the OSI model. Further, such software drivers manage individual physical devices on system buses, rather than individual functions on multipurpose devices.